Robot control, training and collaboration in an immersive virtual reality environment

ABSTRACT

System and methods to create an immersive virtual environment using a virtual reality system that receives parameters corresponding to a real-world robot. The real-world robot may be simulated to create a virtual robot based on the received parameters. The immersive virtual environment may be transmitted to a user. The user may supply input and interact with the virtual robot. Feedback such as the current state of the virtual robot or the real-world robot may be provided to the user. The user may train the virtual robot. The real-world robot may be programmed based on the virtual robot training.

This invention was made with government support under contract number1227277 awarded by The National Science Foundation (NSF) NationalRobotics Initiative. The government has certain rights in the invention.

FIELD OF INVENTION

Embodiments relate to programming dexterous entities and morespecifically to robot training in a virtual reality environment.

SUMMARY

Aspects of the invention may involve systems, devices, and methods. Inone embodiment, a method may be provided for programming a robot. Themethod may include creating an immersive virtual environment (IVE) usinga virtual reality system (VRS); receiving, by the VRS, parameterscorresponding to a real-world robot; creating, by the VRS within saidIVE, a virtual robot, wherein the virtual robot is a simulation of thereal-world robot based on the received parameters; transmitting, by theVRS, a representation of said IVE to a user; receiving, by the VRS,input from the user, wherein said VRE is configured to allow the user tointeract with the virtual robot using said user input; providing, by theVRS within said IVE, robot feedback to the user, wherein said robotfeedback includes a current state of the virtual robot; training, in theVRS, the virtual robot in the IVE by the user; and programming, by theVRS, the real-world robot based on the virtual robot training.

In another embodiment, a system to program a robot may be provided. Theprogramming system may include a dexterous machine with at least onearticulating arm; a processor operable to perform instructions to:create an immersive virtual environment (IVE); receive parameterscorresponding to the dexterous machine; create in said IVE a virtualrepresentation of said dexterous machine based on the parameters;transmit said IVE to a user; receive input from the user, wherein saidinput includes interactions of the user with objects within the IVE;providing in said IVE feedback from said dexterous machine, wherein saidfeedback includes a current state of said dexterous machine; andtransmit programming instructions to said dexterous machine.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other features and advantages of the invention will beapparent from the following, more particular description of variousexemplary embodiments, as illustrated in the accompanying drawingswherein like reference numbers generally indicate identical,functionally similar, and/or structurally similar elements. The firstdigits in the reference number indicate the drawing in which an elementfirst appears.

FIG. 1 depicts an example real-world robot with a wire grasper;

FIG. 2 illustrates an example stereo view of a robot with a programmedtrajectory being played back in a virtual environment;

FIG. 3 depicts example information flow between human and robot;

FIG. 4 depicts example exocentric view for interacting with a robot;

FIG. 5 depicts example egocentric view for interacting with a robot;

FIG. 6 shows an example overlay virtual information display;

FIG. 7 depicts an example virtual user interface showing a trajectoryrecording menu attached to a virtual user's hand;

FIG. 8 depicts an example virtual user interface showing the recordingmenu with additional contextual options;

FIG. 9 depicts an example virtual user interface showing a helperobject;

FIG. 10 depicts an example virtual user interface attached to a virtualrobot;

FIG. 11 depicts an example virtual lead-through programming;

FIG. 12 depicts replaying a demonstrated trajectory on a virtual robotusing a separate interface to load and playback motion trajectories;

FIG. 13 displays a virtual user interface menu for managing helperobjects;

FIG. 14 depicts creating a cube helper object;

FIG. 15 depicts using handles to resize a helper object;

FIG. 16 depicts constraining the motion of the robot to the side of ahelper object;

FIG. 17 shows an embodiment programming a demonstration with a virtualtool attached to a virtual robot;

FIG. 18 depicts an illustrative workflow for training a dexterousentity;

FIG. 19 depicts a virtual Point cloud view of a pick-and-place task;

FIG. 20 depicts a box plot of position error across various viewpoints;

FIG. 21 depicts a box plot of completion time across various viewpoints;

FIGS. 22-24 depict a plot of error versus completion time for each userunder each interaction mode; and

FIG. 25 depicts an illustrative embodiment of a computer for performingthe methods and building the systems described herein.

DESCRIPTION OF THE EMBODIMENTS

Exemplary embodiments are discussed in detail below. While specificexemplary embodiments are discussed, it should be understood that thisis done for illustration purposes only. In describing and illustratingthe exemplary embodiments, specific terminology is employed for the sakeof clarity. However, the embodiments are not intended to be limited tothe specific terminology so selected. A person skilled in the relevantart will recognize that other components and configurations may be usedwithout parting from the spirit and scope of the embodiments. A personskilled in the relevant art will recognize that the various embodimentsor components of the various embodiments may be combined and/orpartially combined. It is to be understood that each specific elementincludes all technical equivalents that operate in a similar manner toaccomplish a similar purpose. The examples and embodiments describedherein are non-limiting examples.

All publications cited herein are hereby incorporated by reference intheir entirety.

As used herein, the term “a” refers to one or more. The terms“including,” “for example,” “such as,” “e.g.,” “may be” and the like,are meant to include, but not be limited to, the listed examples. Theterm “dexterous entity” may refer to a robot such as a robotic arm orany robot that may move and require programming. The term “immersivevirtual environment” may refer to a virtual reality environmentdisconnected from the real-world, augmented reality where visual imagesand/or audio may be introduced or projected into the real-world, and/oraugmented virtuality where real world objects are represented in avirtual world. An immersive virtual environment (IVE), Immersive VirtualRobotic Environment (IVRE), or Virtual Reality Environment (VRE) may beany immersive digital workspace. This may include stereoscopic 3Ddisplays on a monitor as well as VR headsets (such as the Oculus Rift™)or augmented reality (AR) devices such as Google Glass™. These maycontain 3D models, point clouds, meshes, as well as articulated 3Davatars or proxies for both the user or any other kinematic system (suchas a robot).

While robotics technology has become the backbone of manufacturing overthe past several decades, small manufacturing entities (SMEs) still facechallenges when trying to integrate robotic systems into theirproduction pipelines. For example, in order for SMEs to benefit fromrobotic technology, they require systems with high flexibility, rapidprogrammability, and cost effectiveness without the economy of scale.Efforts to improve industrial robot programming have not provided theflexibility required for small scale, short run change-out tasksperformed by SMEs. Immersive Virtual Reality (VR) has the potential toprovide the flexible human-robot interaction tools required by thedynamic human-robot interaction patterns of SMEs. The IVRE interactionparadigm may provide a set of requirements and design patterns fordeveloping VR interfaces for flexible industrial human-robotinteraction.

Robotics technology has become the backbone of manufacturing over thecourse of the past several decades, yet small manufacturing entities(SMEs) are characterized by a number of requirements which distinguishthem from more canonical manufacturing contexts. In order for SMEs tobenefit from robotic technology, systems with high flexibility, rapidprogrammability, and cost effectiveness without the economy of scale maybe needed. These requirements, along with the constraints imposed by theindustrial environment, necessitate a paradigm for how human operatorsprogram, collaborate and generally interact with robots which may bedifferent than many other human-robot interaction (HRI) domains.

What is needed is a method for improved control, training andcollaboration with a robotic system using a Virtual Reality Environment(VRE). Current methods of programming robots for a specific task (e.g.,a teaching pendant) are cumbersome, time consuming and unintuitive.Other methods for teaching via force control require physicalmanipulation of the robot in its active state, and therefore arerestricted to human-safe robots and to demonstrations than can be easilyguided in this manner. With VRE, the user may alternate between variousperspectives such as egocentric (first person) and exocentric (thirdperson) perspectives to control the robot directly, train or programmotions for the robot to make later, or interactively collaborate withthe robot during a task execution. Additionally, a user may interactwith dynamic 3D graphical user interfaces and interface objects, whichallow for additional control, mode changing, data retrieval ormonitoring of other systems. These interactive widgets may be placed ina user centric position so as to utilize the user's proprioceptive cuesfor easier activation or manipulation. General tools for interactionwith a robot in a VRE may be available, such as gestures, utilizingspatial locations to represent different system configurations, andtools to manage the control of either a completely simulated robot, or areal world system represented by a simulated virtual proxy.

FIG. 1 depicts an example robot 110 with a wire grasper in a work cell.Robot 110 may be used by, for example, an SME that manufactures wirebaskets. A frequent task for this example SME is to transfer bentwire-forms from a commercial CNC wire bender 120 to a welding fixture.To incorporate robot 110 into this task, a user might, for example, (a)teleoperate the robot and maneuver it into an acceptable startingposition, (b) record the trajectory required to grab a wire-form fromthe bender 120 and place it in the fixture, and then (c) monitor therobot 110 during the execution of the task and halt it if there are anyerrors. This task exemplifies how human-robot interaction modes in asmall manufacturing task may cover a range of relationships between theuser and robot and how the relationships may change during the executionof the task.

Robot 110 is depicted in FIG. 1 as an industrial robot arm with a wiregrasper. Robot 110, however, is not limited to this embodiment. Instead,robot 110 could embody other industrial robot forms, a domestic robot,an articulated welding robot, an autonomous robot, a military robot, amedical robot, or other robot or robotic embodiments.

While the above listed interaction modes may be similar to thoseinvolved in larger-scale manufacturing, an SME operator needs to be ableto, for example, perform multiple robotic task specifications fordifferent products during an equivalent number of production hours.

A teach pendant may be used to instruct robot 110. However, currentlyavailable teach pendants may be limited by a static graphical userinterface, a mismatch between control degrees of freedom and those ofthe robot, and a lack of feedback about the outcome of the program.Improvements to teach pendants may include designing them with humanfactors considerations, retrofitting the graphical user interface,augmenting the pendant with simulated views of the robot, adding gestureand voice control, and integrating 6-DOF joysticks. Additionally,kinesthetic, lead-through, or force-guided interaction may be used toinstruct robots. While these enable intuitive physical programming bydemonstration (PbD), kinesthetic guidance is also limited by arelatively high learning curve and the requirement of physicalinteraction which may not be possible when a robot is interacting withlarge or dangerous machinery or when the robot is in a remote location.Additional flexibility is still required for small scale, short runchange-out tasks performed by SMEs.

An immersive virtual environment (IVE) may provide a flexiblehuman-robot interaction tools required by the dynamic human-robotinteraction patterns in tasks like the one described above. Immersive VRmay remove the requirement of physical interaction with the robot andreplaces physical robot co-presence with virtual robot co-presence in anatural 3D environment. In this context, a user or trainer may share avirtual environment with a visualization of the real robot where he orshe can look at, move around, and touch virtual interfaces for roboticinteraction. This means intuitive metaphors for interaction like thoseused in kinesthetic programming may be preserved. This virtualenvironment also enables the free-form creation of arbitrary displaysand interfaces to support the flexible human-robot interactionrequirements of SME tasks.

In an embodiment, an Immersive Virtual Robotic Environment (IVRE) may beprovided to train industrial robots for SMEs and other locations. Inimmersive VR, interaction with industrial systems from the user'sviewpoint and control mapping to the robot and task space may beprovided.

Augmented reality (AR) and virtual reality (VR) for robotic systems areboth meant to make interaction with robots more flexible by combiningdigital information in a more intuitive manner with a physical system.AR involves projecting virtual information on top of a real physicalenvironment, while VR involves displaying a representation of thephysical system in a virtual digital environment.

Augmented reality for tele-robotic control may be performed using, forexample, stereoscopic overlays of object models and virtual toolsdisplayed to a user on a 3D screen or with see-through HMDs.Additionally, PbD methods through the use of AR to visualize robotsingularities and define compliance parameters may be provided. Further,users may select scene objects and other task locations using augmentedreality, which may allow the user to interact with the environment at ahigher level via object-based programming rather than, for example,coordinate programming. Marker-less gesture recognition may be provided,where a user's interaction with objects combined with input from anaugmented reality display may be used to define robot tasks. Further,tracking a user's head position and orientation in 3D space andinteractive virtual menus which the user may operate using gestures maybe provided.

The control mapping between the human operator and the robot may be acritical feature of any VR system. In one embodiment, a system forprogramming a robot may be provided that uses an egocentric (firstperson) control mapping to the robot. FIG. 2, for example, shows anexample stereo view of a robot with a programmed trajectory being playedback in a virtual environment. The system may also include an exocentric(third person), (e.g., over the shoulder) view of the robot and thescene. First person perspective may increase immersion and performancefor certain tasks. However, giving users the ability to switch betweenfirst and third person perspective at will may be preferable to beingfixed to either one. This trade-off between egocentric and exocentricviewpoint and control mappings is of importance to VR-HRI and isprovided in the embodiments described herein.

FIG. 2 uses, for example, Oculus Rift™, which is a head-mounted display(HMD) that includes head tracking for virtual environments, similartools may be used. FIG. 2 depicts virtual environment 200 (e.g., IVRE)containing a hand avatar 220, selectable options, and virtual robot 210.

In an embodiment, an IVRE may provide, for example, the ability tocontrol (e.g., move in real-time or near real time), program (e.g.,assign movement patterns for later execution), or collaborate (e.g.,interact with autonomous robot behavior) with a robotic system (eitherremote or locally) using a VRE via, for example, a 3D avatar of therobotic system 210. Further, the ability to, in a VRE, use a combinationof first person or third person user perspective to control, program orcollaborate with the robot 210. For example, the first person mode mayinvolve moving a robot's end effector around with the appearance to theuser that the robot's “hand” is their hand. In this case, the user'savatar would be co-located with the robot's graphical representation ina manner to suggest the two are as one. Third person mode may involvegrabbing the robot's effector and moving it around as if the user wasmanipulation a tool.

Other embodiments may include managing Off-Line Simulated Robots and/orReal-World Robots with a Simulated Proxy. The ability to switch betweeninteraction with an off-line simulation of a real world robotic systemand a real-time or delayed proxy representation of that same robot maybe provided. For example, a robot 110 in a factory may be trained byfirst creating a trajectory sequence using a simulated off-line virtualrobot 210, and then during the execution of that trajectory on the realworld system, interacting with that real world system on-line via thesame virtual robot as a proxy.

Additional embodiments may include the following. The ability to useeither user commands or programmatic events to switch between off-linesimulation and on-line proxy interaction modes. The ability to switch anon-line proxy representation of a robotic system between multiple realworld systems of similar configuration in real time. For example, usinga single virtual robot to control several identical real world robots byswitching which real world robot the virtual proxy represents. Theability to concurrently multiplex a recorded trajectory, task plan orother behavior on an off-line simulated robotic system to multiple realworld systems of the same configuration. For example, recording atrajectory on a virtual simulated robot, and then simultaneously playingback that trajectory on five real world robotic systems. The ability tointeract with several real world systems via a single on-line proxyrepresentation in a manner where when a real world system is not linkedwith the proxy, it will behave in a preprogrammed or pre-trainedfashion. For example, while five real world robots are performing atask, the user selects one to be linked with the proxy to re-task thatrobot because of a flaw in the part.

The flow of information in the human-robot collaborative system must bereviewed to design an effective VR interaction paradigm for industrialrobots. FIG. 3 depicts example information flow 300 between human 390and robot 110. Information flow 300 includes the following. In 310, datafrom task 305 such as task parameters and/or task constraints may besupplied to robot 110 (e.g., task knowledge to the robot). In 320, datafrom task 305 may be supplied to the user 390 (e.g., task knowledge tothe user). In 330, user 390 may supply data in the form of controlsignals to robot 110 (e.g., control information from the user to robot).In 340, robot 110 may supply data to user 390 (e.g., information aboutthe robot's state to the user). In 350, environment 315 may supplysensing data to robot 110 (e.g., environment knowledge to the robot). In360, environment 315 may supply scene data to user 390 (e.g., sceneknowledge about the environment to the user).

The relationship between user 390 and the robot 110 for a given task(e.g., the role of the user) may determine the required frequency,fidelity and latency of information flow for a given task. For example,user 390 teleoperating robot 110 requires low-latency, high-frequency,high-degree-of-freedom (DOF) control, as well as real-time feedback fromthe robot about its state. However, when programming robot 110, user 390additionally must supply information about workspace and velocityconstraints and temporal logic about the task, as well as invokediscrete commands such as enabling/disabling motion recordings, forexample. In 330, for example, user 390 may only monitor robot 110 andtherefore may require much less frequent control input and robot statefeedback. In one embodiment, a human-robot system (e.g., 300) hasinterface primitives with corresponding interaction metaphors thatsupport all of the information flows (e.g., 310-360), as well as theability to switch the modality of these interfaces as user roles change.

Therefore, an embodiment of the IVRE meets the following threerequirements:

Enable real-time monitoring and interaction with an industrial robot ina manner similar to kinesthetic guidance. This provides an intuitivemodality for programming from demonstration as well as generalteleoperation.

Provide flexibility for different user roles in the human-robot system.The IVRE supports a wide range of interface primitives that enable theknowledge transfer channels of FIG. 3.

Embed information and displays into the virtual environment. Enable asmuch interaction as possible through the head-mounted display (e.g.,Oculus Rift™) and motion sensors (e.g., Razer Hydra™), eliminating theneed for external peripherals such as a mouse or keyboard.

What follows is a description of basic interaction metaphors with thevirtual environment and a discussion of the different interfaceprimitives that constitute the IVRE interaction paradigm

In one embodiment, the virtual environment may take the form of any 3Drepresentation of an indoor or outdoor environment (e.g., a 10×10 meterroom) in which user has a stereoscopic viewpoint of the virtual space,and in which that user 390 may virtually move around. This environmentmay be generated by placing either laser scanned 3D assets from a realworld scene, or artist created assets approximating a real world scene,into a 3D environment generated by OpenGL or another graphics library.This freedom of movement allows one or more users user 390 to virtuallymove closer or further to task elements depending on the perceptual andmotor requirements of the task. User 390 may look in any directionusing, for example, head tracking in the head-mounted display (e.g.,Oculus Rift™). User movement in the virtual environment may beaccomplished by, for example, joystick input (e.g., Razer Hydra™ wands).The position and orientation of the user's viewpoint in the virtualenvironment follow their head motion, motion commanded from a joystick,or their physical motion, as determined by a body tracking device orsensors. In one embodiment, the user may be represented by right andleft hand avatars. The hand avatars may follow the position of the usershands via motion sensors held by user 390 (e.g., Razer wands), and maybe calibrated to user's head so they appear proprioceptively aligned. Inanother embodiment, the user may be represented by a full body avatarthat represents the position and orientation of the user's own body andjoints. This can be supplied by a full body tracking system such as theKinect or Vicon tracking systems. The user can additionally switch theirviewpoint arbitrarily by any other interface, causing them to jump or“teleport’ in the virtual environment. The user may also change theenvironment at will, for instance to rapidly switch between a virtualrepresentation of two separate factory floors. Furthermore, any user inthe shared environment can interact with any virtual entity.

Robot 110 may be represented by virtual robot 210, a 3D model or scan ofan existing real robot. This virtual representation may either show asimulation (e.g., off-line) of the robot generated from the kinematicsof the real robot, or the actual state of the robot (e.g., on-line) byupdating the virtual robot's position, orientation or joint values tomatch the real robot. The simulation could use the same kinematic anddynamic model of the robot, but rather than receiving feedback from theactual robot about its joint positions and forces, the simulation coulduse the dynamic model of the robot and estimations of joint positionbased on current velocity. User 390 may interact with the real worldrobot 110 via the virtual robot 210 (and in effect moving the realrobot). Such interaction would could be performed by generating aCartesian pose for the robot end effector to move to (this pose could begenerated by user input, buy a saved trajectory, or other interfaces)and commanding the simulation controller to generate an appropriate setof joint angles to determine the resulting joint pose of the robot. Inorder to control the real robot by proxy, either the same Cartesianendpoint pose could be commanded to the real robot (which would beresolved by the real robot controller), or the joint positions of thevirtual robot could be replicated on the real robot, using PID controlto command the real robot joints to the desired angles. The user mayalso visualize the real world task space around robot 110 using either apoint cloud of the scene from an RGBD camera, or via a stereo view froma robot-attached stereo camera, for example. The data generated from thecamera or depth camera is created either as a sprite in the 3Denvironment (in the case of 2D camera data) or as a cloud of 3D pointobjects (in the case of depth or 3D sensor data). In one embodiment,interactions with virtual entities (tools, GUIs, virtual robots) takeplace via selection by proximity. For example, when the user places hisor her hand avatar 220 near an interactive entity, the distance will becalculated between the users hand avatar and the entity. Should thatdistance be below some threshold, (e.g. such as the radius of the sphereenclosing the entity) that entity will be “selected”, which is displayedas a change in color or transparency, change in entity shape, orconfiguration. Selection can also occur via or via “picking” (i.e. GLpick) where a entity is considered selected when the user's avataroccludes the entity from the visual perspective of the user. Selecteditems, for example, can then be “grabbed” or “pressed” by activating abutton on the controller (e.g., Hydra Wand™). In another embodiment,entities can be selected by a ray emanating from the user's hand avatar.When this ray intersects the entity, that entity is now “selected”.Additionally, an entity can be selected by a rigid body collision of theuser's hand avatar and the entity, assuming the environment supportscollision detection.

When interacting with virtual robot 210, user 390 can not only interactfrom an exocentric (third person) perspective but also from anegocentric or first person perspective. FIG. 4 depicts exampleexocentric view for interacting with virtual robot 210. FIG. 5 depictsexample egocentric view for interacting with virtual robot 210. Theegocentric perspective allows user 390 to place themselves “inside”virtual robot 210 and operate it from the robot's point of view. This isenabled by placing the user's viewpoint in such a position that thevisible virtual geometry of the robot overlaps with the spatial regionthat would normally correspond to the user's arm. Instead of seeingtheir own arm, they see the robot's arm, allowing the user to makenatural movements with his or her own arm and see the robot arm behavingin the same way. This allows the user to have more of a proprioceptivegrounding in the control of virtual robot 210. Conversely, theexocentric perspective allows user 390 to use his or her visualperception of the scene, for example leaning in to examine fine detailsof the scene closely to make precise adjustments. The user's viewpointis fixed to be in alignment with virtual robot 210 for egocentric and itis mobile for exocentric perspectives.

Combining conflicting viewpoints and control mappings, (e.g.,controlling the robot exocentrically from an egocentric viewpoint (orvice versa)) requires the motion of the user's virtual hand and therobot's end effector to be decoupled, which breaks the interactionparadigm of kinesthetic guidance. However, specifically having anexocentric viewpoint with an egocentric control mapping can be usefulwhen the task scale is larger than the human's workspace.

In a human-collaborative system, there are several requirements forpresenting information to the user in various forms. These include (seeFIG. 3, 300), for example, task information, robot state information,and environment information. As discussed above, the user'svisualization of the physical task space may be achieved by a 3D pointcloud rendered in the virtual environment. Information about thereal-world robot 110 may be visualized primarily by the robot proxy(e.g., virtual robot 210), where user 390 may view virtual robot 210 andthereby inspect the physical configuration of robot 110.

Other information such as alphanumerical information about robot 110, orinformation about task 305 may be displayed by virtual informationdisplays VIDs. VIDs can be created programmatically by the system or canbe spawned on demand by the user, using any input interface. VIDs arecreated as 2D or 3D sprites in the virtual environment that are texturedwith a pre-generated texture. This texture can display text, staticimages, video streams or 2D visual information. VIDs may provide theability to use 3D information displays to monitor robot state, textualinformation, video feeds or other information from one or multiplerobotic systems.

VIDs may be moved around by the user (or programmatically), or attachedto arbitrary transformation frames in the environment. This is achievedby enforcing that the pose of the VID in the 3D environment to followthe positional frames of the user or other entities in the environmentthrough a static geometric transform. In this way VIDs can be “attached”to the user or robot, to follow his or her position.

The VID may be locked to a robotic avatar, by creating a staticgeometric transformation between some reference frame on the robot andthe VID. An example could be joint information displayed on the joint ofthe robot, using a static transformation between the VID and theshoulder joint frame of the robot. The display may present joint angleinformation and be locked to the robot's shoulder joint, so that italways shows the joint angle at the position of the joint, regardless ofthe robot's motion.

In an embodiment, the VID may be locked to (or relative to) the user orto user's avatar. For example a textual display that always hovers near(or is always visible by) the user no matter where they move in thevirtual environment, by creating a static transformation between theuser's torso frame and the VID. Or, keeping a clock VID in the sameposition in the user's view, relative to their head frame, so the clockis always visible no matter the orientation of the user's view. Or, lockthe clock VID to the user's forearm frame, so the user may look down attheir arm (or hold up their arm) to see the time, regardless of theirbody position. An example VID may be seen in FIG. 2.

Mixed reality user interfaces (UIs) in a VRE may also be provided. Forexample, the ability to use 3D interactive graphical user interfaces(widgets) in the VRE, which may be adjusted by the user (moved,rescaled). These widgets may be textured or shaded in any aesthetic orartistic manner. For example, a floating panel of buttons that may be“pressed” by the user, moved in the environment, and/or resized. Theability to “dock” 3D widgets with the user's own 3D avatar, so as toenable interaction via the user's proprioceptive cues. For example, thebutton panel may be locked to stay at the user's elbow by temporarilyenforcing a transform between the panel and the users elbow frame, andin that manner, the user need only use proprioceptive cues to touchtheir elbow (in a natural manner) to activate the widget. The user couldthen undock or dismiss the widget when desired. The ability to lock theposition of 3D widgets with respect to either the user or another avatarin the scene may also be provided. The button panel may be locked at aset distance from the user's torso, so that it moves relative to theuser and always stays in reach as the user moves within the VRE. Theability to lock the position of a 3D widget with respect to anotheravatar (or moving 3D representation) in the scene. In another example,locking the button widget to the side of the robot so it remains on therobot's side regardless of robot avatar motion may also be provided.Mixed reality interfaces can also include visual cues that take the formof color or shape changes in existing geometry or textures. These cuescan be used to provide force information for the robot, proximity alertsto hazardous regions, signify robot motor temperatures, etc.

VIDs may also be assigned in an overlay mode, where they are rendered ontop of all other scene entities, to provide an experience similar toaugmented reality overlays. FIG. 6 shows an example overlay virtualinformation display VIEWPOINT SELECTION that is showing textualinformation about the state of the menu. FIG. 6 displays a view of theviewpoint selection virtual user interfaces (VUI), including buttons forselecting egocentric, exocentric and overview (e.g., a few meters fromthe robot) viewpoints. Also shown is the VIEWPOINT SELECTION overlay VIDwhich follows the user's gaze direction and remains on top of otherscene geometry. Because we want to mitigate any refocusing of the user'seyes, which can cause fatigue, we want the interface geometry to be inthe same visual plane as the geometry over which the interface isdisplayed. Since geometry the user is interacting with is typically nearinfinity, the solution is to make the interface much larger and furtheraway than the geometry. By then rendering the interface after thegeometry, the interface appears on top, and properly sized because ofthe distance away from the user.

To address the requirement of discrete control signals from the user tothe robot (e.g., 330 in FIG. 3), an embodiment IVRE may support virtualuser interfaces (VUIs). Similar to information displays, virtual userinterfaces are 3D graphical objects that can provide the functionalityof buttons, drop down or radial menus, or toggles. Interaction withinterfaces may also follow the proximity selection mentioned above.These are implemented as textural regions that each map to a specificcommand. For instance, a VUI might consist of a panel of three buttons.Each button has its own interaction region, where it is considered“selected”, that can be activated by proximity to the user's avatar, viaa ray from the user's hand intersecting the region, or via “picking”(i.e. GL pick) where the a region is considered selected when the user'savatar occludes the region from the visual perspective of the user. Alsosimilar to VIDs, VUIs can be attached with respect to virtual frames andentities in the environment.

FIGS. 7-10 depict example virtual user interfaces. Following the designof VIDs, VUIs can be attached to frames such as the virtual robot 210 oruser. FIG. 7 depicts an example virtual user interface showing atrajectory recording menu attached to a virtual user's hand. Therecording menu VUI may by attached and follow the virtual user's hand oravatar.

FIG. 8 depicts an example virtual user interface showing the recordingmenu with additional contextual options. For example, once the stopbutton is pressed, additional options may be displayed.

FIG. 9 depicts an example virtual user interface showing a helperobject. For example, helper objects such as a sphere, cube, or cylindermay be created. The helper objects may be deleted by dragging the objectto the trash, as shown in FIG. 9. Accordingly, more complex behavior mayinclude moving an object to or near a VUI to perform an action (e.g.,delete object).

FIG. 10 depicts an example virtual user interface attached to a virtualrobot. In FIG. 10, for example, an attached user interface may followthe position of the end effector, as shown with the motion constraintmenu in FIG. 10.

For interfaces attached to the user, such as in FIG. 7 where the VUImenu follows the position and orientation of the users hand avatar, theuser can use proprioceptive cues for activating menus, or make intuitivegestures to enact VUI functionality, such as a “look at your watch”gesture to show or hide a VUI menu.

In another embodiment, to address the transfer of task knowledge (suchas motion trajectories) to robot 110 via the user 390 (e.g., 340 in FIG.3), as well as continuous control signals to robot 110 (as duringteleoperation), IVRE supports simulated kinesthetic control of robot 110via the proxy robot 210. To move robot 110, the user places his or hervirtual hand 220 within a specific radius of interaction around therobot's 210 end effector (marked by a translucent sphere). Once inside,a button press may enable robot's 210 end effector to follow theCartesian position and orientation of the user's 390 hand. This providesa similar interaction modality as “grabbing on” to the real robot 110.The user can also move the robot using input from a VUI, or fromgestures made in the virtual environment, such as a “pushing away”gesture that causes the robot to retreat from the user. This metaphorhas limitations from the standpoint of scaling as well as humanworkspace size (limited by the user's arm reach length). If user 390needs to interact with a virtual object that is farther than they canreach, the only option they have is to move towards the object, but theymight want to keep his or her viewpoint while interacting with distantitems. If the user is interacting with the aforementioned projected rayselection method, this interaction method can be used to interact with adistant virtual object. The user can also spawn a local copy of avirtual object that is within interaction reach, which causes the copiedobject to perform the same motions or actions as the local object.

To record motion trajectories, for example, user 390 may enable avirtual user interface which provides buttons to enable and disablemotion recording save or discard recordings. FIG. 11, shows an examplevirtual lead-through programming. In FIG. 11, for example, a trajectorymay be demonstrated with lead through programming using the robot proxy210. FIG. 12 depicts replaying the demonstrated trajectory on the proxyrobot 210 using a separate interface to load and playback motiontrajectories. By replaying the robot 210 motion may be validated beforecommanding the trajectory to the real robot 110. The trajectory can bevisualized by a spline or a series of waypoints, or by a sequence ofvisualizations of the virtual robot itself in different configurations.The user can also supply a trajectory to the robot by demonstrating atrajectory themselves, using their hand avatars and virtual objects. Forinstance, the user could grab a drill virtual object, and demonstrate adrilling motion, which the robot could replay.

Training virtual robot 210 in a virtual environment has the addedbenefit that the robot proxy can be moved and trained off-line, withrespect to live data from the scene, and that trained action can bereplayed off-line as well. This means user 390 can carefully examine theaction and its consequences before deciding to cancel, redo, improve ordeploy it on the real robot 110.

In one embodiment, the IVRE may allow for the creation of interactivevirtual helper objects (VHOs), which can take the form of deformablegeometric primitives. These interactive helper objects may have severaluses such as motion constraint, representing task information, andrepresenting environment information, for example.

FIG. 13 displays a VUI menu for managing helper objects. For example, tospawn a sphere, cube or cylinder, or the option to drag a created objectto the trash. The ability to create, spawn or define manipulatablegeometric primitives (cubes, spheres, rectangular prisms, etc.) ordetailed 3D mesh objects as overlays of real time sensing data (such asa 3D point cloud) to define geometric regions for robotic interaction inthe real world may be provided. For example, given a point cloudrepresenting some real world geometry is available in the VRE (e.g., asa laser scan of a kitchen table with a ball on it), the user can “draw”a sphere around the region of the point cloud that represents the ball,to enable the robot to pick up the ball

FIG. 14 depicts creating a cube helper object from the VUI menu. Inaddition to geometric primitives, VHO may be 3D meshes such as tools orother shapes.

FIG. 15 depicts using handles to resize the helper object into a flatrectangular shape, for example.

FIG. 16 depicts constraining the motion of robot 210 to the side of thehelper object. In FIG. 16, the rectangular VHO constrains the robot'smotion so that it is co-planar with the VHO. Helper objects may becreated and used to define a constraint which the virtual robot 210 andthe real robot 110 will follow. The ability to interactively definevirtual constraints for the robot motion in the VRE, which are thentranslated to physical constraints in the physical world may beprovided. The rectangular primitive may be used as a keep out zone wherethe robot (both virtual and real) cannot enter.

As with kinesthetic teaching, a user's 390 motions are often not preciseenough to be used directly for a given task. VHOs may be used as, forexample, virtual fixtures to provide constraints on the motion of theuser's hand avatars, or the motion of objects in the environment, or themotion of the robot. This constraint takes place with respect to thevirtual fixture using some geometric null space projection. This canallow for more precise input.

3D widgets or meshes may be created that may modify the view behindthem, providing a “magic window” to look through for additionalinformation or inspection. For example, a sprite that can be manipulatedby the user that shows a thermal view of the robot when placed in theuser's view of the robot. Real-time 2D or 3D video or depth (pointcloud) information on the virtual scene may be displayed overlaid in ageometrically correct manner on any 3D representations in the VRE. Forexample, 3D point cloud of a table in front of the robot may bedisplayed in the VDE in the correct position and orientation relative tothe robot's virtual proxy representation. Similarly a 2D video streammay be positioned in the VRE according to the viewpoint of the physicalcamera, with respect to the robot.

FIG. 17 shows an embodiment programming a demonstration with a virtualtool attached to a virtual robot 210. Virtual objects may representtools, and may also represent task information more generally.Interactive 3D meshes of tools or other objects may be provided orcreated that may then be used as a robot training or control proxy. Forexample a 3D drill model (mesh) may be spawned, which user 390 may graspin the VRE and manipulates, but in the physical world, the robot 110 hasan attached drill and is replicating the user's motion. Also, user 390could “hand” the robot 210 a drill VHO (e.g., FIG. 17). Such an action,could start a subroutine in the background that loads task parametersrelated to a previously defined drilling task, such as tool parametersfor kinematic and dynamic action, trajectories, and other taskparameters This may be an intuitive way to give high level informationto the robot about pre-programmed tasks that follows how humans oftenrepresent a task as the tool used to accomplish it. Tool VHOs could alsobe used to train users with a novel device before performing action onthe real robot 110.

In another embodiment, the VRE could be used to train a user to interactwith a physical robot, by providing exactly the same interface to thereal robot as is available in real life. Furthermore, the VRE could beused to train a user a specific programming or task specificationlanguage in the “safe” virtual environment, where they can experimentwith the simulated robot without any physical recourse.

Combination 3D meshes/UI/VIDs may also be created that can bemanipulated by the user as, for example, tools may be provided. Forexample, a 3D mesh shaped like a tablet computer, which may display a UIor VID on its “screen.” The combination interfaces may be docked withthe user's avatar for storage. For example, the tablet may be hung onthe user's belt for later use.

In one embodiment, VHOs may also be used for interactive perception.Because VHOs may be moved and resized, user 390 could place a VHO over areal world scene object in the virtual point cloud, and scale the VHO tothe correct size. This serves to define the location and extent of thephysical object with respect to the real robot, by mapping the virtuallyspecified position (using the VHO) to the coordinate system of the realrobot., That physical object's positional information can then be usedby the robot for interaction with the object. This is an intuitivemethod for transferring scene information to the robot, (the equivalentof one human user saying to another “the ball is there” while pointingat a ball) which might not be equipped with scene parsing algorithms,for example.

In one embodiment, multiple robots (local, remote, or a combination) maybe managed via IVRE avatars. The ability to represent remote, butgeographically co-located systems in the VRE by grouping them closetogether in the VRE may be provided. For example, user 390 may becontrolling four robots, two in a local factory, and two in a factory inanother state. The avatars representing the local robots may be next toone another, but on one side of the virtual environment (a room) whilethe two robots in the other state will be near each other, but acrossthe other side of the room. The ability to represent uncertainty about astate of a robot (or delay in the state information) using graphicalcues, either directly on the 3D avatar of the robot or using 3Dgraphical widgets may be provided. For example, if the information abouta remote robot becomes stale, or delayed, the information display (orthe robot avatar itself) could become more and more transparent. In thecase of a VUI displaying the information, it could change color withincreasing staleness.

In one embodiment, gestures may allow for communication. The ability foruser gestures to move, dismiss, evoke or otherwise interact with both 3DUIs, VIDs or 3D models (such as the representation of the robot itself)may be provided. For example, a notification VUI can be dismissed byflicking it away. The ability to use the interaction of gestures with 3Dentities (such as a robot avatar) to enact real world events may beprovided. For example, a user may shut down a robot by pushing itsavatar away in the VRE. The ability to navigate in third person modeusing a “grab and pull” gesture may be provided. For example, if a userneeds to travel some distance in the VRE, and therefore reaches forwardwith both hands, grabs with both hands, and then pulls towards his body,which causes him to move some distance in the VRE. The ability toengage/disengage from control/interaction with a robot avatar in firstperson perspective using gestures may be provided. For example, when therobot's end effector is following the user's hand position in firstperson mode, the user can wave with the other hand to disengagefollowing.

FIG. 18 depicts an illustrative workflow for training a dexterousentity. In 1810, an immersive virtual environment (IVE) may be created.The IVE may be created within a virtual reality system. The virtualreality system may be created using an OpenGL graphical environment,with a stereoscopic display viewpoint, coupled with a head mountedstereo display, which can track the user's position and orientation, andmap that into the virtual environment as a change in viewpoint. A set ofhand or body tracking devices can provide a real time avatar of theuser's hand or body positions. Software may then update the virtualviewpoint based on the user's position and orientation, as well as headposition and orientation, to create a fully immersive experience. Withinthe virtual reality system, the IVE may be created using 3D scenecontent to create a virtual environment, 3D and 2D textured meshes andsprites to create entities that the user can interact with, a 3Dtextured mesh of the robot, and other 3D data from real time or recordedsensor data. Software may provide interaction between the user's virtualrepresentation and entities in the environment, by interaction distanceor ray casting. Other software may update real world assets such as arobot based on changes made in the virtual environment. The virtualenvironment may also simulate a physics based environment, where objectsact appropriately due to the force of gravity or other simulatedenvironments, such as the gravity of other planets. Such an IVE may alsoinclude collision models, or dynamic models for entities to enablecollision or deformation. The user may also switch between differentIVEs without changing the physical configuration of the system. The IVEmay include a virtual reality environment, an augmented realityenvironment (e.g., an augmented environment), or augmented virtuality.

In one or more embodiments, the IVE may be used as a sandbox, forexample, for learning robot programming or task plan specification usingsaid virtual robot; multiple users and/or multiple robots may interfacewith the same IVE; the IVE may display a real time representation ofreal life environments with the ability to seamlessly transition betweenthe real life environment and the virtual environment; and/or the IVEmay display the forces applied by the robot, or other objects, as sensedby the real world robot. From 1810, flow may move to 1820.

In 1820, parameters may be received to describe a real-world dexterousentity (e.g., robot 110, an industrial robot, a domestic robot, anarticulated welding robot, an autonomous robot, a military robot, amedical robot, etc.). The parameters may be used by the IVE to create avirtual representation of the real-world dexterous entity (e.g., virtualrobot 210). The virtual dexterous entity may have the same limitationsand features as the real-world dexterous entity, by using the kinematicand dynamic model of the robot, as well as the appearance model of therobot to provide a robot that moves, acts and looks just as the realrobot does. This includes kinematic limitation such as joint limits,singularities and self-collisions. For instance, the kinematic model ofthe robot could be created from the Denavit-Hartenberg parameters of therobot, and combined with Lagrange's equations to create a dynamic modelfor the robot. The dynamic and kinematic model of the robot are thenincorporated into the control software for the real robot, and thesimulation control software of the virtual robot. The real-worlddexterous entity may be remotely operated a distance from the user(e.g., in another state, in the ocean, in space, etc.), located in ahazardous environment, and/or too dangerous for the user to be in closeproximity. From 1820, flow may move to 1830.

In 1830, the virtual dexterous entity may be created in the IVE. Thevirtual dexterous entity representing a simulation of the real-worlddexterous entity. The virtual dexterous entity may represent one or morereal-world dexterous entities. From 1830, flow may move to 1840.

In 1840, the virtual reality system may transmit the IVE to a user 390.The user 390 may view the IVE using one or more visual devices (e.g.,one or more monitors, a stereoscopic 3D display, a virtual realityheadset, an augmented reality device, virtual reality goggles, augmentedreality glasses, Oculus Rift™, Google Glass™, etc.). The IVE may alsotransmit sound to the user 390 through one or more audio devices (e.g.,speakers, headsets, earphones, etc.). This sound can be static, or canbe generated in a geometrically appropriate manner based on the positionor orientation of the user in the environment (for instance, the soundfrom the robot gets louder when the user is closer to the virtualrobot).

In one embodiment, the IVE may be configured to: define virtualconstraints for the virtual robot, where the virtual constraints may betranslated physical constraints imposed on the real-world robot; displayreal-time 2D or 3D video or depth information on a virtual sceneoverlaid in a geometrically correct manner on any 3D representation inthe IVE; and/or display forces applied by the robot, or other objects,as sensed by the real-world robot.

User 390 may view the virtual dexterous entity multiple perspectives,and these multiple perspectives may be selectable by user 390. Forexample, the user 390 may view the dexterous entity from an egocentricperspective, where the user 390 operates the virtual dexterous entityfrom a point of view of the virtual dexterous entity. For example, animage of an arm of the virtual dexterous entity may be overlaid where anarm of user 390 would be in real life. In another perspective, user 390may view the virtual dexterous entity inside the IVE from a point ofview external to the virtual dexterous entity (e.g., exocentricperspective). From 1840, flow may move to 1850.

In 1850, the IVE may receive input from the user 390. User 390 maysupply input using one or more sensors to detect body position anddirection, and other input devices (e.g., joystick, button, keyboard,mouse, etc.) Body position sensors may detect head direction andposition (e.g., Oculus Rift™), arm position and direction, hand position(e.g., Razor Wands™), body position, and the body position of more thanone user. This includes both body orientation and the spatial locationof the user with respect to some physical coordinate system. User 390input may provide interaction with the virtual dexterous entity. In oneembodiment, the motions of the virtual dexterous entity correspond inreal-time (or near real-time) to that of the real-world dexterousentity. User 390 may program the virtual dexterous entity using avirtual user interface. From 1850, flow may move to 1860.

In 1860, feedback may be provided from the IVE to user 390. Feedback mayinclude a virtual information display (VID), wherein the virtualinformation display may include a 2D sprite or a 3D mesh. Additionally,the VID may be textured or shaded. The VID may be locked to the virtualdexterous entity, locked to a view of the user, and/or locked to anavatar of the user. The IVE may also include mixed reality userinterfaces (UIs). This could include a physical peripheral, such as atablet, that the user holds, which matches the position of a virtualtablet with respect to the user's viewpoint. This means that UIs may beconfigured to be adjusted by the user, locked to an avatar of the user,locked to the virtual dexterous entity, and/or locked with respect tothe viewpoint of the user.

The IVE may provide user 390 the ability to define geometric primitivesor detailed 3D mesh objects. These objects may be overlays of real timesensing data to define geometric regions for interaction for thereal-world dexterous entity. The IVE may provide user 390 with theability to define virtual constraints for the virtual dexterous entity.The virtual constraints may be translated into physical constraintsimposed on the real-world dexterous entity. The IVE may also providereal-time 2D or 3D video or depth information on a virtual sceneoverlaid in a geometrically correct manner on any 3D representation inthe IVE. In one embodiment, the virtual information displays (e.g., VID,UIs) provided to user 390, may be placed on the other side of a visualscene so that the information is rendered on top of the scene and is notplaced between the user's and the scene.

In one embodiment, the IVE may not provide the user with the ability tophysically feel the touch of virtual objects. Instead, the IVE mayprovide an interaction zone alerting user 390 that the user 390 mayinteract with an object. For example, when user 390 moves an avatarclose to a button object, an indication may be provided to alert user390 that the button may be pressed. For example, a button may glow, theopacity of the robot may change, vibration, and/or a sound may betransmitted to user 390. Visual cues can also be used in the virtualenvironment to denote forces on the robot. For instance, parts of therobot avatar could glow red if the force exerted by the robot is toogreat. From 1860, flow may move to 1870.

In 1870, the virtual dexterous entity may be trained by user 390 withinthe IVE. Such training includes dexterous entity motion and tasks. Oncea series of motions and tasks have been given to the virtual dexterousentity, the virtual dexterous entity can replay the instructions to user390.

From 1870, flow may move to 1880.

In 1880, the real-world dexterous entity receives the training providedto the virtual dexterous entity. For example, robot 110 is programmedwith the instructions given to the virtual robot 210. The transmissionof instructions from virtual robot can take place in two ways. First, ifthe virtual robot has exactly the same kinematic and dynamic model asthe real world robot, then any trajectories or waypoints instructed tothe virtual robot then can be used immediately by the real system.Should the real system differ in kinematic or dynamic model, thensoftware may translate any Cartesian trajectories or waypoints into thereference frame of the real robot, provided that the robot has the samedegrees of freedom. T virtual robot and real robot drivers may beconnected by a network interface. Finally, any task programs or plansthat are instructed to the virtual robot may be directly used by thereal robot assuming the hardware capabilities of the robot match thevirtual robot (i.e. if the task plan calls for grasping an object, thereal robot must have a gripper). This is also the case for transferringinstructed information from a real system to a virtual system, assumingthe above constraints.

Using the IVE, user 390 may receive training on the real-world dexterousentity or other real-world tools by first using the virtual dexterousentity or a virtual tool in the IVE. By using the embodiments disclosedherein, robots may be programmed in a safe environment and one that isintuitive to the user 390. As the robot programming is performed at ahigh level, user 390 will not need detailed robotic programmingknowledge to re-task or initially program one or more robots.

In one embodiment, an IVRE was implemented on a physical testbedconsisting of a 6-DOF American Robot Merlin™ welding robot, with aRobotiq 2-Finger Adaptive Gripper as an end effector. Sensing wasaccomplished by a PrimeSense Carmine™ RGBD camera, rigidly attached to aworkbench placed inside the workspace of the robot.

The IVRE was implemented on top of the Robot Operating System (ROS) as aseries of loadable software objects that can be spawned by RVIZ, a robotvisualization environment in ROS that uses Ogre as its 3D engine. Theseobjects augment the standard RVIZ package to allow for the virtualinteraction described in this document. Visualization of the virtualenvironment was accomplished by using the OculusVR® Rift stereo display,which incorporates ultra-low latency head orientation tracking. Forinput, the Razer Hydra motion controller was used, which tracks the6-DOF position and orientation of two hand-held wands and providesadditional input such as analog joysticks and buttons.

To characterize IVRE for use as an industrial robot interface, apreliminary comparison of different virtual control viewpoints andcontrol mappings as well as a comparison of visualization modalities forreal-time viewing of the robot's physical task space was conducted.

For the first analysis, a test to compare what effect egocentric andexocentric perspective has on efficiency of performing tasks in VR wasperformed. The task was an object placement task as seen in FIG. 19.FIG. 19 depicts a virtual Point cloud view of a pick-and-place task. Theefficiency of performing the task in terms of accuracy in position,orientation, and speed was measured. The object used in the task was anoctagonal wood block measuring 35 mm wide and 140 mm tall, and the taskflow was to pick it up and place it atop an identical block with asclose as possible alignment.

The user 390 was placed in IVRE and controlled the robot 210 withvirtual kinesthetic guidance using Razer Hydra wands. Two sets of testswere performed, with each test consisting of three trials each. In thefirst test the users were in an exocentric perspective, where the user'sviewpoint is co-located with the robot, and the robot directly mimicsthe user's actions. In the second task the user was in an egocentricperspective, where the robot followed the user's actions relative to theuser's perspective. In exocentric perspective, the user was free to movearound in the virtual space arbitrarily.

To compare the efficiency of using IVRE to traditional robot operationmethods, the same task as above was performed without the virtualreality component. The virtual exocentric viewpoint was replaced withthe user controlling the robot with Razer Hydra wands using their owneyesight, in a position approximately 1 meter from the robot (outsideits reachable workspace). Because it is not possible for the user tophysically assume a first person position with respect to the robot, theegocentric perspective was replaced with a PointGray Bumblebee stereocamera, attached to a tripod and placed in a first person position abovethe robot, aligned with the virtual egocentric viewpoint with respect tothe robot. The task was otherwise identical. Since the user has novirtual interaction sphere to grab on in real life, the interaction wasmodified so that the user could “grab” the robot from any position bypulling the trigger of the Razer wand. The motion of the robot wouldthen start relative to that initial hand position.

FIG. 20 depicts a box plot of position error across various viewpoints.As shown in FIG. 20, real vision provided better performance (smallerposition error) than virtual reality, however, virtual reality accuracyand speed was comparable to real vision. In fact, as can be seen inFIGS. 22-24 (depicting a plot of error versus completion time for eachuser under each interaction mode), the performance of egocentric andexocentric viewpoints in real life was very closely tied to theirvirtual reality counterpart. Thus, virtual reality is a close analoguefor the task in both viewpoints in terms of precision.

FIG. 21 depicts a box plot of completion time across various viewpoints.As can be seen in FIG. 21, neither type of viewpoint had a considerableadvantage in terms of speed over the other, both in real life and invirtual reality. It is noteworthy that the task took a slightly longertime in VR.

Due to the octagonal blocks used having a width of 35 mm, placementerrors of 18 mm or greater caused the placed object to topple and fall,which was deemed as the user failing the task. As can be seen in FIGS.22-24, the only time the users failed the task was when they were inegocentric views, both virtual and real.

Exocentric mappings have a demonstrable advantage over egocentric onesin terms of accuracy, while having comparable speed (e.g., FIG. 21).This can be tied to several observations noted below.

The ability to move to an arbitrary perspective to better align theblock was noted by the subjects as the biggest advantage of thisperspective. While the subjects noted that the increased proprioceptionfrom the egocentric perspectives helped with immersion, they also notedthat the robot's arm occluding the workspace made the task harder.

One outcome that was not anticipated, was users hitting the joint limitsof the robot and getting stuck more often in egocentric view thanotherwise. The ability to monitor the robot's state in exocentric viewsprevented this from occurring during those tests. While the addedimmersion and proprioceptive control of egocentric perspectives providedadvantageous in fine manipulations of the end effector of the robot, dueto the arm of the robot not being kinematically similar to a human arm,the robot was overall more difficult to maneuver precisely in this view.

Another interesting aspect of the test was that all three participantsperformed differently, both in terms of trajectory of motion andquantifiable results, as seen in FIGS. 22-24. In the exocentric virtualtask, one user preferred to view the robot gripper from the side whenpicking the object up and from ahead when placing it; whereas anotheruser did the exact opposite. This speaks to the flexibility of theexocentric viewpoint and the fact that users were able to take theposition they were comfortable with is shown by the higher accuracy andlower speed of those viewpoints compared to the egocentric ones.Conversely, not only users did not spend time on adjusting theirperspective in egocentric views, they also spent less time adjusting thegripper's angle of approach due to the intuitive mapping between theirhand and the gripper, and this is apparent in the time results for theegocentric perspective. Generally, users typically picked a viewingposition that is mostly co-axial with the point cloud source. Thisraises questions about how users cope with partial information from RGBDsensors.

One other instance of a user doing the tasks differently than otherswas, instead of just placing the block on top of the target and lettingit go after aligning, this user rested the block on the target andpushed it around, using the slack in the grippers to nudge the blockinto place before letting go. The high fidelity of the Razer wands wasable to capture subtle motions like this and emulate kinestheticguidance without actual contact between the user and the robot.

Generally, the experience with the Oculus Rift as a display and trackingdevice was positive. With the caveat that this is a first-generationdevice, the tracking was low latency with few temporal image artifacts.The resolution of the display, being only 720×640 pixels per eye, wassomewhat low, but it did not have any detrimental effect on ourexperiments. Additionally, the fact that the device only tracks userhead orientation and not position, was slightly disorienting becausetranslation of the user's head did not invoke any 3D movement in thescene. Future versions of the device promise higher resolution, positiontracking and better latency. The mapping between the views from thestereo camera and each eye's display in the Oculus Rift was differentfrom user to user, as users had different inter-pupillary distance whichled to the vergence of the images needing to be calibrated betweenusers.

Additional features include manipulating a robot from a distance in thevirtual environment. For example, if a user is trying to make the robotmove an object while viewing the robot from afar in the virtualenvironment, they may not be able to grab the robot and guide it. Infact, they may not be able to interact with any virtual entity that isnot within arm's reach. This problem may be solved by casting a ray fromthe user's hand to distant objects to “pick” them and interact withthem. Other features include the ability to modify the scale between theuser's mapping and the robot's actions. If the user wanted to makeextremely precise motions, they could map the robot to move at a scaleddown speed compared to their virtual hands. Conversely, they could alsomake the robot move much faster with small motions. This may drasticallyimprove work flow and efficiency for tasks depending on how muchprecision they demand.

FIG. 25 depicts an illustrative computer system that may be used inimplementing an illustrative embodiment of the present invention.Specifically, FIG. 25 depicts an illustrative embodiment of a computersystem 2500 that may be used in computing devices such as, e.g., but notlimited to, standalone or client or server devices. FIG. 25 depicts anillustrative embodiment of a computer system that may be used as clientdevice, or a server device, etc. The present invention (or any part(s)or function(s) thereof) may be implemented using hardware, software,firmware, or a combination thereof and may be implemented in one or morecomputer systems or other processing systems. In fact, in oneillustrative embodiment, the invention may be directed toward one ormore computer systems capable of carrying out the functionalitydescribed herein. An example of a computer system 2500 is shown in FIG.25, depicting an illustrative embodiment of a block diagram of anillustrative computer system useful for implementing the presentinvention. Specifically, FIG. 25 illustrates an example computer 2500,which in an illustrative embodiment may be, e.g., (but not limited to) apersonal computer (PC) system running an operating system such as, e.g.,(but not limited to) MICROSOFT® WINDOWS® NT/98/2000/XP/Vista/Windows7/Windows 8, etc. available from MICROSOFT® Corporation of Redmond,Wash., U.S.A. or an Apple computer or tablet executing MAC® OS, OS X, oriOS from Apple® of Cupertino, Calif., U.S.A., or a computer running aLinux or other UNIX derivative. However, the invention is not limited tothese platforms. Instead, the invention may be implemented on anyappropriate computer system running any appropriate operating system. Inone illustrative embodiment, the present invention may be implemented ona computer system operating as discussed herein. An illustrativecomputer system, computer 2500 is shown in FIG. 25. Other components ofthe invention, such as, e.g., (but not limited to) a computing device, acommunications device, a telephone, a personal digital assistant (PDA),an iPhone, an iPad, a Surface, and Android device, a 3G/4G wirelessdevice, an LTE device, a wireless device, a personal computer (PC), ahandheld PC, a laptop computer, a smart phone, a mobile device, anetbook, a handheld device, a portable device, an interactive televisiondevice (iTV), a digital video recorder (DVR), client workstations, thinclients, thick clients, fat clients, proxy servers, networkcommunication servers, remote access devices, client computers, servercomputers, peer-to-peer devices, routers, web servers, data, media,audio, video, telephony or streaming technology servers, etc., may alsobe implemented using a computer such as that shown in FIG. 25. In anillustrative embodiment, services may be provided on demand using, e.g.,an interactive television device (iTV), a video on demand system (VOD),via a digital video recorder (DVR), and/or other on demand viewingsystem. Computer system 2500 and/or parts of computer system 2500 may beused to implement dexterous entity, robot 110, virtual robot 210,immersive virtual environment, and/or other components as described inFIGS. 1-2, 4-17, and 19 and techniques described in FIGS. 3 and 18.

The computer system 2500 may include one or more processors, such as,e.g., but not limited to, processor(s) 2504. The processor(s) 2504 maybe connected to a communication infrastructure 2506 (e.g., but notlimited to, a communications bus, cross-over bar, interconnect, ornetwork, etc.). Processor 2504 may include any type of processor,microprocessor, or processing logic that may interpret and executeinstructions (e.g., for example, a field programmable gate array(FPGA)). Processor 2504 may comprise a single device (e.g., for example,a single core) and/or a group of devices (e.g., multi-core). Theprocessor 2504 may include logic configured to executecomputer-executable instructions configured to implement one or moreembodiments. The instructions may reside in main memory 2508 orsecondary memory 2510. Processors 2504 may also include multipleindependent cores, such as a dual-core processor or a multi-coreprocessor. Processors 2504 may also include one or more graphicsprocessing units (GPU) which may be in the form of a dedicated graphicscard, an integrated graphics solution, and/or a hybrid graphicssolution. Various illustrative software embodiments may be described interms of this illustrative computer system. After reading thisdescription, it will become apparent to a person skilled in the relevantart(s) how to implement the invention using other computer systemsand/or architectures.

Computer system 2500 may include a display interface 2502 that mayforward, e.g., but not limited to, graphics, text, and other data, etc.,from the communication infrastructure 2506 (or from a frame buffer,etc., not shown) for display on the display unit 2501. The display unit2501 may be, for example, a television, a computer monitor, iPad, amobile phone screen, Oculus Rift™, Google Glass™, a stereoscopic 3Ddisplay, a virtual reality headset, an augmented reality device, virtualreality goggles, augmented reality glasses, etc. The output may also beprovided as sound through, for example, headphones, speaker(s), etc.

The computer system 2500 may also include, e.g., but is not limited to,a main memory 2508, random access memory (RAM), and a secondary memory2510, etc. Main memory 2508, random access memory (RAM), and a secondarymemory 2510, etc., may be a computer-readable medium that may beconfigured to store instructions configured to implement one or moreembodiments and may comprise a random-access memory (RAM) that mayinclude RAM devices, such as Dynamic RAM (DRAM) devices, flash memorydevices, Static RAM (SRAM) devices, etc.

The secondary memory 2510 may include, for example, (but is not limitedto) a hard disk drive 2512 and/or a removable storage drive 2514,representing a floppy diskette drive, a magnetic tape drive, an opticaldisk drive, a compact disk drive CD-ROM, flash memory, etc. Theremovable storage drive 2514 may, e.g., but is not limited to, read fromand/or write to a removable storage unit 2518 in a well-known manner.Removable storage unit 2518, also called a program storage device or acomputer program product, may represent, e.g., but is not limited to, afloppy disk, magnetic tape, optical disk, compact disk, etc. which maybe read from and written to removable storage drive 2514. As will beappreciated, the removable storage unit 2518 may include a computerusable storage medium having stored therein computer software and/ordata.

In alternative illustrative embodiments, secondary memory 2510 mayinclude other similar devices for allowing computer programs or otherinstructions to be loaded into computer system 2500. Such devices mayinclude, for example, a removable storage unit 2522 and an interface2520. Examples of such may include a program cartridge and cartridgeinterface (such as, e.g., but not limited to, those found in video gamedevices), a removable memory chip (such as, e.g., but not limited to, anerasable programmable read only memory (EPROM), or programmable readonly memory (PROM) and associated socket, and other removable storageunits 2522 and interfaces 2520, which may allow software and data to betransferred from the removable storage unit 2522 to computer system2500.

Computer 2500 may also include an input device 2503 which may includeany mechanism or combination of mechanisms that may permit informationto be input into computer system 2500 from, e.g., a user. Input device2503 may include logic configured to receive information for computersystem 2500 from, e.g. a user. Examples of input device 2503 mayinclude, e.g., but not limited to, a joystick, a mouse, pen-basedpointing device, or other pointing device such as a digitizer, a touchsensitive display device, and/or a keyboard or other data entry device(none of which are labeled). Other input devices 2503 may include, e.g.,but not limited to, a biometric input device, a video source, an audiosource, a microphone, a web cam, a video camera, a light-sensitivedevice, and/or other camera. Still other input devices 2503 may include,e.g., but not limited to, an imaging device, a light-sensitive device,sensing elements, body position and direction sensors (e.g., RazorWands™, Wii controllers, etc.), accelerometers, gyroscopes, and/ormagnetometers.

Computer 2500 may also include output devices 2515 which may include anymechanism or combination of mechanisms that may output information fromcomputer system 2500. Output device 2515 may include logic configured tooutput information from computer system 2500. Embodiments of outputdevice 2515 may include, e.g., but not limited to, display 2501, anddisplay interface 2502, including displays, printers, speakers, cathoderay tubes (CRTs), plasma displays, light-emitting diode (LED) displays,liquid crystal displays (LCDs), printers, vacuum florescent displays(VFDs), surface-conduction electron-emitter displays (SEDs), fieldemission displays (FEDs), etc. Computer 2500 may include input/output(I/O) devices such as, e.g., (but not limited to) input device 2503,communications interface 2524, cable 2528 and communications path 2526,etc. These devices may include, e.g., but are not limited to, a networkinterface card, and/or modems.

Communications interface 2524 may allow software and data to betransferred between computer system 2500 and external devices.

In this document, the terms “computer program medium” and “computerreadable medium” may be used to generally refer to media such as, e.g.,but not limited to, removable storage drive 2514, a hard disk installedin hard disk drive 2512, memory unit, flash memories, removable discs,non-removable discs, etc. In addition, it should be noted that variouselectromagnetic radiation, such as wireless communication, electricalcommunication carried over an electrically conductive wire (e.g., butnot limited to twisted pair, CATS, etc.) or an optical medium (e.g., butnot limited to, optical fiber) and the like may be encoded to carrycomputer-executable instructions and/or computer data that embodimentsof the invention on e.g., a communication network. These computerprogram products may provide software to computer system 2500. It shouldbe noted that a computer-readable medium that comprisescomputer-executable instructions for execution in a processor may beconfigured to store various embodiments of the present invention.References to “one embodiment,” “an embodiment,” “example embodiment,”“various embodiments,” etc., may indicate that the embodiment(s) of theinvention so described may include a particular feature, structure, orcharacteristic, but not every embodiment necessarily includes theparticular feature, structure, or characteristic.

Further, repeated use of the phrase “in one embodiment,” or “in anillustrative embodiment,” do not necessarily refer to the sameembodiment, although they may. The various embodiments described hereinmay be combined and/or features of the embodiments may be combined toform new embodiments.

Unless specifically stated otherwise, as apparent from the followingdiscussions, it is appreciated that throughout the specificationdiscussions utilizing terms such as “processing,” “computing”“calculating” “determining,” or the like, refer to the action and/orprocesses of a computer or computing system, or similar electroniccomputing device, that manipulate and/or transform data represented asphysical, such as electronic, quantities within the computing system'sregisters and/or memories into other data similarly represented asphysical quantities within the computing system's memories, registers orother such information storage, transmission or display devices.

In a similar manner, the term “processor” may refer to any device orportion of a device that processes electronic data from registers and/ormemory to transform that electronic data into other electronic data thatmay be stored in registers and/or memory. A “computing platform” maycomprise one or more processors.

Embodiments of the present invention may include apparatuses forperforming the operations herein. An apparatus may be speciallyconstructed for the desired purposes, or it may comprise a generalpurpose device selectively activated or reconfigured by a program storedin the device.

Embodiments may be embodied in many different ways as a softwarecomponent. For example, it may be a stand-alone software package, or itmay be a software package incorporated as a “tool” in a larger softwareproduct. It may be downloadable from a network for example, a website,as a stand-alone product or as an add-in package for installation in anexisting software application. It may also be available as aclient-server software application, or as a web-enabled softwareapplication. A general purpose computer may be specialized by storingprogramming logic that enables one or more processors to perform thetechniques indicated herein and the steps of or descriptions shown in,for example, FIGS. 3 and 18.

Embodiments of the present invention may include apparatuses forperforming the operations herein. An apparatus may be speciallyconstructed for the desired purposes, or it may comprise a generalpurpose device selectively activated or reconfigured by a program storedin the device.

Embodiments may be embodied in many different ways as a softwarecomponent. For example, it may be a stand-alone software package, or itmay be a software package incorporated as a “tool” in a larger softwareproduct. It may be downloadable from a network, for example, a website,as a stand-alone product or as an add-in package for installation in anexisting software application. It may also be available as aclient-server software application, or as a web-enabled softwareapplication.

The following references are incorporated by reference in theirentirety:

-   T. Pettersen, J. Pretlove, C. Skourup, T. Engedal, and T. Lokstad,    “Augmented reality for programming industrial robots,” in Mixed and    Augmented Reality, 2003. Proceedings. The Second IEEE and ACM    International Symposium on, October 2003, pp. 319-320.-   M. Rahimi and W. Karwowski, “A research paradigm in human-robot    interaction,” International journal of industrial ergonomics, vol.    5, no. 1, pp. 59-71, 1990.-   A. Aryania, B. Daniel, T. Thomessen, and G. Sziebig, “New trends in    industrial robot controller user interfaces,” in Cognitive    Infocommunications (CogInfoCom), 2012 IEEE 3rd International    Conference on. IEEE, 2012, pp. 365-369.-   S. Pieska, J. Kaarela, and O. Saukko, “Towards easier human-robot    interaction to help inexperienced operators in smes,” in Cognitive    Infocommunications (CogInfoCom), 2012 IEEE 3rd International    Conference on, December 2012, pp. 333-338.-   A. Kazi, J. Bunsendal, D. Haag, R. Baum, and R. Bischoff, “Next    generation teach pendants for industrial robots,” in Advances in    Human-Robot Interaction.-   Springer, 2005, pp. 47-66.-   S. Calinon, “Robot programming by demonstration,” in Springer    handbook of robotics. Springer, 2008, pp. 1371-1394.-   T. Hulin, V. Schmirgel, E. Yechiam, U. E. Zimmermann, C. Preusche,    and G.-   Pohler, “Evaluating exemplary training accelerators for    programming-by-demonstration,” in RO-MAN, 2010 IEEE. IEEE, 2010, pp.    440-445.-   P. Milgram, A. Rastogi, and J. J. Grodski, “Telerobotic control    using augmented reality,” in Robot and Human Communication, 1995.    RO-MAN'95 TOKYO, Proceedings., 4th IEEE International Workshop on.    IEEE, 1995, pp. 21-29.-   S.-K. Ong, J. Chong, and A. Y. Nee, “Methodologies for immersive    robot programming in an augmented reality environment,” in    Proceedings of the 4th international conference on Computer graphics    and interactive techniques in Australasia and Southeast Asia. ACM,    2006, pp. 237-244.-   A. A. E., B. Akan, and B. Cürüklü, “Augmented reality meets    industry: Interactive robot programming,” in SIGRAD 2010, November    2010, pp. 55-58.-   J. Lambrecht, M. Kleinsorge, M. Rosenstrauch, and J. Krüger,    “Spatial programming for industrial robots through task    demonstration.” International Journal ofAdvanced Robotic Systems,    vol. 10, 2013.-   S. Tachi, H. Arai, and T. Maeda, “Tele-existence simulator with    artificial reality (1)-design and evaluation of a binocular visual    display using solid models-,” in Intelligent Robots, 1988., IEEE    International Workshop on, October 1988, pp. 719-724.-   R. H. Jacoby and S. R. Ellis, “Using virtual menus in a virtual    environment,” in SPIE/IS&T 1992 Symposium on Electronic Imaging:    Science and Technology. International Society for Optics and    Photonics, 1992, pp. 39-48.-   N. E. Miner and S. A. Stansfield, “An interactive virtual reality    simulation system for robot control and operator training,” in    Robotics and Automation, 1994. Proceedings., 1994 IEEE International    Conference on. IEEE, 1994, pp. 1428-1435.-   L. Hamon, P. Lucidarme, E. Richard, and P. Richard, “Virtual reality    and programming by demonstration: Teaching a robot to grasp a    dynamic object by the generalization of human demonstrations,”    Presence: Teleoperators and Virtual Environments, vol. 20, no. 3,    pp. 241-253, 2011.-   M. Slater, V. Linakis, M. Usoh, and R. Kooper, “Immersion, presence,    and performance in virtual environments: An experiment with    tri-dimensional chess,” in ACM virtual reality software and    technology (VRST). Citeseer, 1996, pp. 163-172.-   F. Ferland, F. Pomerleau, C. T. Le Dinh, and F. Michaud, “Egocentric    and exocentric teleoperation interface using real-time, 3d video    projection,” in Human-Robot Interaction (HRI), 2009 4th ACM/IEEE    International Conference on. IEEE, 2009, pp. 37-44.-   J. Scholtz, “Theory and evaluation of human robot interactions,” in    System Sciences, 2003. Proceedings ofthe 36th Annual Hawaii    International Conference on. IEEE, 2003, pp. 10-pp.-   L. B. Rosenberg, “Virtual fixtures: Perceptual tools for telerobotic    manipulation,” in Virtual Reality Annual International Symposium,    1993., 1993 IEEE. IEEE, 1993, pp. 76-82.-   M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, R.    Wheeler, and A. Y. Ng, “Ros: an open-source robot operating system,”    in ICRA workshop on open source software, vol. 3, no. 3.2, 2009.-   R. Belousov, R. Chellali, and G. J. Clapworthy. Virtual reality    tools for internet robotics, volume 2, pages 1878-1883, 2001.-   G. C. Burdea. Invited review: the synergy between virtual reality    and robotics. Robotics and Automation, IEEE Transactions on,    15:400-410, 1999.-   E. Freund and J. Rossmann. Projective virtual reality: Bridging the    gap between virtual reality and robotics. Robotics and Automation,    IEEE Transactions on, 15:411-422, 1999.-   J. Funda and R. P. Paul. Efficient control of a robotic system for    time-delayed environments, pages 219-224, 1991.-   M. S. Kadavasal, A. Seth, and J. H. Oliver. Virtual reality based    multi-modal teleoperation using mixed autonomy. ASME Conference    Proceed-ings, 2008:1451-1460, 2008.-   A. Kheddar, E.-S. Neo, R. Tadakuma, and K. Yokoi, volume 31,    chap-ter Enhanced Teleoperation Through Virtual Reality Techniques,    pages 139-159. 2007.-   P. Milgram, S. Zhai, D. Drascic, and J. J. Grodski. Applications of    augmented reality for human-robot communication, volume 3, pages    1467-1472, 1993.-   A. Monferrer and D. Bonyuet. Cooperative robot teleoperation through    virtual reality interfaces, pages 243-248, 2002.-   J. Savage-Carmona, M. Billinghurst, and A. Holden. The virbot: a    virtual reality robot driven with multimodal commands. Expert    Systems with Applications, 15:413-419, 1998.-   M. A. Sheik-Nainar, D. B. Kaber, and M.-Y. Chow. Control gain    adap-tation in virtual reality mediated human-telerobot interaction.    Human Factors and Ergonomics in Manufacturing & Service Industries,    15:259-274, 2005.-   T. Takahashi and H. Ogata. Robotic assembly operation based on    task-level teaching in virtual reality, pages 1083-1088, 1992.-   H. Yamada, N. Tao, and Z. Dingxuan. Construction tele-robot system    with virtual reality, pages 36-40, 2008.-   European Patent App. EP 20,100,184,620, and WO Patent Application    Publication Nos. PCT/1132003/005,543 and PCT/US2009/069,350

While various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample only, and not limitation. Thus, the breadth and scope of thepresent invention should not be limited by any of the above-describedillustrative embodiments, but should instead be defined only inaccordance with the following claims and their equivalents.

1. A method for programming a robot comprising: creating an immersivevirtual environment (IVE) using a virtual reality system (VRS);receiving, by the VRS, parameters corresponding to a real-world robot;creating, by the VRS within said IVE, a virtual robot, wherein thevirtual robot is a simulation of the real-world robot based on thereceived parameters; transmitting, by the VRS, a representation of saidIVE to a user; receiving, by the VRS, input from the user, wherein saidVRS is configured to allow the user to interact with the virtual robotusing said user input; providing, by the VRS within said IVE, robotfeedback to the user, wherein said robot feedback includes a currentstate of the virtual robot; training, in the VRS, the virtual robot inthe IVE by the user; and programming, by the VRS, the real-world robotbased on the virtual robot training. 2.-28. (canceled)